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ABSTRACT 



A processing system for controlling a computer graph- 
ics display stores and processes bit-mapped digital pixel 
values to generate color display signals. The system 
incorporates memory elements for storing control val- 
ues for each pixel, in association with color values for 
each pixel. Processing modules responsive to the per- 
pixel control and color values generate color display 
signals. Embedding per-pixel control information in the 
bitmap in association with per-pixel color information 
enables each pixel to independently control the opera- 
tion of the processing modules on that pixel. 
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1 2 

marked for a "fast clear mode" so as to reduce the time 
DISPLAY CONTROLLER UTILIZING ATTRIBUTE required to clear a window. The screen-wide display 

BITS mode could be replaced by per-pixel display mode spec- 
ification. Although commonly such specification will 

BACKGROUND OF THE INVENTION 5 vary on a per-window basis, per-rectangle sub-win- 

The present invention relates generally to the field of dows, per-object, and even per-pixel variation would 

digital computers, and, in particular, relates to appara- also be useful, 

tus for controlling computer graphics displays. It is thus an object of the invention to provide an 

Multiprocessing graphics workstations known in the improved computer graphics display controller system, 
art have the capability to run several applications or 10 It is a further object of the invention to provide a 
display different images concurrently. Such multipro- computer graphics display controller system which 
cessing graphics workstations typically employ bitmap allows for flexible configuration of an image memory, 
planes with per-screen control information, rather than it is another object of the invention to provide a 
color information, as a general mechanism to support computer graphics display controller system in which 
per-screen video display mode specification. Display 15 tne mode or configuration by which pixels are inter- 
modes include selecting false color or real color, or preted can be fl ex ibly varied across a display screen, 
using particular sections of a color lookup table. It - a a further object of the mvention to prov i de a 

The high cost of bitmap memory and the difficulty in computer grap hics display controller system which 

achieving yery fast memory cycle times in physically m a ixd dis h mode spec i flcation . 

large RAM arrays has limited the resolution and plane 20 ft ^ ^ Qf ^ iavw&m ide & 

count provided by bitmaps. False color configura- ute Wcs di j contro i, er system which 

tions having four, eight or twelve planes have become a « * ... j • j- i i_ j • iL ,• 

popular compromise between the cost of deep bitmaps ^ f a f er dynamlc ******* by reducin S the tlme 

and the desire for realistic colors. In a false color mode, re 1 mred for cleann S a new buffer - 

all three red, green and blue (RGB) lookup tables 25 SUMMARY OF THE INVENTION 

(LUTs) receive data values from the same planes. In a _..,., 

real color mode, three sets of planes are used, with each The mention achieves the above objects by provid- 

set routed to a single LUT. In § a svstem f° r embedding per pixel control informa- 

Recently, as RAM densities have soared, bitmap tion in the bitmap in addition to the color information, 
resolution and plane count have increased. 1 -MByte and 30 so that each pixel can control its own interpretation by 
4-Mbyte Video RAMs will continue this trend. Color the video-generating hardware, said hardware includ- 
lookup tables have also grown as static RAM density tug a plane multiplexor. The invention discloses a digital 
improves. Greater resolution has allowed engineering processing system for controlling a computer graphics 
graphics workstations to usefully display multiple im- display, wherein the system stores and processes digital 
ages or contexts on the same screen, and additional 35 picture element (pixel) values corresponding to each of 
planes and larger lookup tables have presented the op- a plurality of display pixels. The system includes storage 
portunity to interpret the bitmap in a variety of ways. A elements for storing first control values in association 
deficiency associated with per-screen display mode with the digital pixel values, and control elements, in 
specification, typical of conventional graphics display communication with the storage elements, and respon- 
systems, however, is that the entire screen is typically 40 s i ve to the first control values, for controlling process- 
interpreted using one display mode. mg performed by the system. 

Typically, a twenty-four plane configuration work- j^ invention further provides attribute or display 

station must run real color, false color, and even mono- mode lookup table apparatus, in association with the 

chrome graphics applications, some of which double- st0 rage elements, and including an array of memory 

buffer images or reload color lookup tables. Since the 45 locations addressable by the first control values. When 

display must be reconfigured or the lookup table altered addressed by the first control values, the attribute 

for each, these applications cannot share the screen m look table apparatus provides corresponding second 

conventional graphics display systems Such whole- CQntrol values which contfol ssi per f rmed by 

screen reconfiguration conflicts with the capability of ,, „„„*„„ r>,„„„,„;„„ „„*■ „„j k„ *uZ *„„♦„„, ;* t u»* 

Ii . . ° ,,.,.• * ■ j ^ t ,„ the system. Processing performed by the system is thus 

multiprocessing workstations to use windows to share 50 ■%. , , . , , . ,, .,, , , 

,, v ° .... specified by control values associated with each pixel, 

the screen among applications. r ™ . J ^ , , c ,. c . 

There is thus a conflict between the paradigm in V* invention includes apparatus for modifying a 

multiprocessing workstations wherein the screen is vanety of display charactenstics by plane multiplexing 

composed of windows or images belonging to several lesp ? a ^ e J° ??"* f ™* 1011 assoaated with each 

independent contexts and the single screen-wide display 55 P lxeL Modifiable disp ay functions include false co or 

interpretation mode such windows must share in con- md ^ color mode selection and control. In false color 

ventional graphics systems. mode ' the same P lanes are routed t0 a11 three red ' S reen 

If such mode information could be associated with wd blue ( RGB ) looku P tables - Conversely, in real color 

windows or pixels rather than the whole screen, each mode - three sets of P lanes are routed separately, each 

application or image could define modes independently, 60 set to a single color lookup table (LUT). 

and applications could share the screen more effec- The invention also provides elements for variation of 

tively. color lookup table origin, responsive to per-pixel con- 

If pixels can select by which "configuration" they are trol information, and in an embodiment having in- 
interpreted, then different windows can be displayed as creased color lookup table size, several applications can 
needed without conflicts. For example, the pixels in one 65 share different areas within the same table, 
window could be marked as "twenty-four plane real The invention also provides apparatus for selecting a 
color", whereas another window could be "eight-plane number of bitmap source planes, responsive to per-pixel 
false color". Moreover, pixels in one window could be control information, including selection of eight, ten, 
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twelve or more planes of false color, or twelve or 
twenty-four plane real color. 

The invention further provides elements for double 
buffer selection which can be made per-window; appli- 
cations can switch buffers independently of each other, 5 
and singly-buffered applications need not write their 
images into more than one buffer. 

The invention also includes apparatus for interpreting 
selected image planes as overlays, responsive to per- 
pixel control information. Applications which do not 10 
use overlays can disregard such selected image planes 
or use them in other ways. The invention also discloses 
elements, responsive to per-pixel control information, 
for forcing constant color, as for cursors, markers, and 
grids, which often are configured to occlude the under- 15 
lying image without corrupting it. 

The invention further includes apparatus responsive 
to per-pixel control information, for executing functions 
which include image filtering, highlighting for "overb- 
right" and "blink" modes, validity or fast clear modes 20 
for substituting background color if a pixel is designated 
invalid, clipping during drawing, and leveling. Leveling 
utilizes a linear equation of the form I=mx+b, for 
offsetting black level and executing a contrast multiply. 

The invention will next be described in connection 25 
with certain illustrated embodiments. However, it 
should be clear that various changes, modifications and 
additions can be made by those skilled in the art without 
departing from the scope of the invention as defined in 
the claims. 30 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a fuller understanding of the nature and objects 
of the invention, reference should be made to the fol- 
lowing detailed description and the accompanying 35 
drawings in which: 

FIG. 1 is a block diagram of a prior art computer 
graphics display controller system; 

FIG. 2 is a block diagram of a computer graphics 
display controller system according to the invention; 40 

FIG. 3 is a block diagram of another embodiment of 
a controller system according to the invention; 

FIG. 4 is a block diagram illustrating the bits of a 
multi-bit mode word; and 

FIG. 5 is a block diagram illustrating bitmap plane 45 
multiplexing configuration utilized in a preferred em- 
bodiment of the invention. 



DESCRIPTION OF ILLUSTRATED 
EMBODIMENTS 



50 



FIG. 1 is a block diagram of a prior art computer 
graphics display controller system 10, which includes 
bitmap 12, plane-routing multiplexor (MUX) 13, display 
mode select logic 15, color lookup tables (LUTs) 14, 
digital to analog converters (DACs) 16-18, and monitor 55 
19. The bitmap 12 of color indexes is typically provided 
by a random access memory (RAM) which stores color 
indexes in an array of addressable locations. Moreover, 
bitmap 12 may be structured in a multiplane memory 
configuration known in the art. The information con- 60 
tained in the bitmap corresponds to picture elements 
(Pixels) on monitor 19, in a manner well known in the 
art. In a conventional display controller system, the 
bitmap stores values corresponding to red, green and 
blue (RGB) video signals. 65 

Bitmap 12 transmits color index signals to plane-rout- 
ing multiplexor 13, which selects from among memory 
planes in bitmap 12, responsive to signals received from 



display mode select logic 15. Digital values stored in 
selected planes are then transmitted to color (RGB) 
lookup tables (LUTs) collectively indicated by refer- 
ence numeral 14. Color LUTs 14 can be provided by a 
plurality of RAMs, or by different sets of memory loca- 
tions within a single RAM structure, as known in the 
art. Thus, in the illustrated system, digital pixel values 
are not routed directly to the DACs 16-18, but are 
instead used as an index into the color LUTs 14. The 
digital value of the indexed color LUT entry is then 
converted to an analog value used to control intensity 
or color on the monitor 19, in a manner known in the 
art. 

The display mode logic 15 indicated in FIG. 1 is a 
static system, i.e., its output is based on the digital values 
transmitted by flipflops. Moreover, the conventional 
bitmap 12 of color indexes does not store display mode 
control values in association with each pixel value. The 
conventional structure illustrated in FIG. 1 thus re- 
quires that pixel values for the entire display screen be 
interpreted according to a single display mode. As dis- 
cussed above, this single-mode-per-screen selection 
conflicts with the capability of multiprocessing work- 
stations to provide multiple windows per screen. In 
particular, using the conventional system, all windows 
sharing a monitor screen would also have to share the 
same display mode. 

Because rectangular windows represent very regular 
patterns in a bitmap, it is possible to make use of such 
regularity in generating pixel interpretation modes as 
the pixel values are transmitted out to become video. A 
wide variety of machines can be envisioned which gen- 
erate programmable display mode information in syn- 
chrony with each window's video. 

However, there is no inherent upper limit as to the 
number of windows or sub-windows which might exist 
on a screen, nor is there any limit to how frequently the 
mode may change on any one scanline of a raster dis- 
play. Indeed, windows can be stacked up, offset by only 
a single pixel each, so the mode must be able to change 
at pixel rates. Without limits on frequency and complex- 
ity, the problem of generating window display mode 
information grows to equal that of emitting pixel colors. 

Accordingly, the general approach utilized in the 
invention is to associate interpretation modes with the 
pixels themselves. Storing such mode information in 
additional planes, in association with the pixel informa- 
tion, delivers it in synchrony with the pixel color infor- 
mation to the video generating hardware without any 
constraints as to window number, position, shape, or 
size. Indeed, objects other than windows can have dif- 
ferentiating interpretation modes, so as, for example, to 
highlight a real-color object by displaying it from a 
different, independently alterable color lookup table. 

The invention, an embodiment of which is illustrated 
as system 20 in FIG. 2, overcomes the deficiencies of 
conventional display controller systems by embedding 
per-pixel control information in the bitmap 22. The 
bitmap 22 is thus a bitmap of color indexes and interpre- 
tation modes. By storing a field of interpretation mode 
bits together with each color index in the bitmap 22, 
each pixel can control its own interpretation by video- 
generating hardware, including plane-routing control 
logic 24, RGB color lookup tables (LUTs) 26, and 
DACs 27-29. 

Referring to FIG. 2, in one embodiment of the inven- 
tion, multiplane bitmap 22 is of dimensions 
1280X 1024x56 bits. In such an embodiment, eight bit 
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red, green and blue color index signals are transmitted 
by bitmap 22 to plane-routing control logic 24. Addi- 
tional RGB signals from bitmap 22 to control logic 24 in 
double-buffered mode are indicated in FIG. 2 by dashed 
lines. 5 

Double buffering, as known in the art, involves stor- 
ing images in two sets of planes, so that one image can 
be displayed on the monitor while another image is 
drawn. Double buffering permits much smoother 
screen motion, and crisper screen update, since only 10 
completed images are displayed. 

Bitmap 22 also transmits to plane-routing control 
logic 24 path selection or interpretation mode signals. 
The mode signals are, in this embodiment of the inven- 
tion, eight bit signals representative of eight bit mode or 1 5 
attribute values stored in bitmap 22 in association with 
each pixel value. 

Plane-routing control logic 24 contains multiplexing 
elements, responsive to the eight bit path selection sig- 
nals, for selecting from among plural bitmap planes. 20 
The operation of such multiplexing elements is known 
in the art. Digital values stored in selected memory 
planes in bitmap 22 are then transmitted to color LUTs 
26. These values are converted to analog values by 
DACs 27-29, and are used as video signals capable of 25 
driving a video monitor. 

The per-pixel multiplexing provided by the system 
20, illustrated in FIG. 2, can be utilized for a variety of 
functions. In one embodiment of the invention, which 
supports applications wherein some display windows 30 
require a real color display mode and other windows 
require false color display, attribute bits stored in bit- 
map 22 are utilized to specify different true color/false 
color modes for each window. 

False color involves using an n-bit color index which 35 
selects between 2" independent colors, with the same 
n-bit index sent to all three RGB LUTs. Real color 
involves using three color indexes, sent separately to the 
RGB LUTs. 

Similarly, in an embodiment wherein RGB LUT size 40 
is increased to accommodate several display applica- 
tions, mode bits are utilized to specify different RGB 
LUT origins. Mode bits can also be used to select the 
number of bitmap source planes. In one embodiment of 
the invention, mode bits are utilized to select between 45 
combinations of eight or ten planes of false color, and 
between combinations of twelve or twenty-four planes 
of real color. 

While the embodiment of the invention illustrated in 
FIG. 2 achieves significant advantages in flexibility of 50 
display mode specification and image memory usage, 
implementation of the simple multiplexing variations 
described above requires eight planes of pixel attributes, 
a 33% increase in bitmap size over a conventional bit- 
map having twenty-four RGB bits. 55 

One solution to this increase in size is to use indirec- 
tion, as illustrated in FIG. 3. If the bitmap control 
planes hold an index into a table of attributes, rather 
than the attributes themselves, then an attribute's infor- 
mation is not limited by the number of bitmap planes; 60 
only the number of uniquely specified sets of attributes 
is limited. Thus, four planes could select among sixteen 
attributes which could be eight bits or more each. The 
capability to support sixteen attributes means that six- 
teen different windows or classes of windows, each 65 
displayed in a different way, could share the screen. 
FIG. 3 illustrates a preferred embodiment of the inven- 
tion which utilizes such mode indexes. 



Referring to FIG. 3, display controller system 30 
utilizes a bitmap 32 of color indexes and interpretation 
mode indexes. The illustrated bitmap element 32 is of 
dimensions 1280x1024x52 bits. Bitmap 32 transmits 
eight-bit RGB signals to plane-routing control logic 35, 
and transmits four-bit mode index signals to interpreta- 
tion mode lookup table 34. Additional RGB signals 
from bitmap 32 to control logic 35 in double-buffered 
mode are indicated in FIG. 3 by dashed lines. In this 
embodiment, interpretation mode table 34 is of dimen- 
sions 16x7 bits. Interpretation mode table 34, addressed 
by the mode index signals from bitmap 32, transmits to 
plane-routing control logic 35 a seven bit path selection 
signal. Plane-routing control logic 35 utilizes the path 
selection signal to select from among bitmap planes, 
using multiplexing circuitry known in the art, and ad- 
dresses color LUTs 36. Digital RGB pixel values from 
LUTs 36 are converted to analog values by DACs 
37-39, and used as RGB video signals to drive a moni- 
tor. 

There is thus one level of indirection in specifying 
each pixel's display mode. Just as the bitmap contains 
color indexes into the color LUT, rather than actual 
color values, so does each pixel's four bit attribute index 
specify which of sixteen attributes to use, rather than 
the attribute itself. This permits modifying the attributes 
associated with many pixels, by simply modifying one 
set of attribute bits. 

Additionally, by using a pixel display mode LUT 34, 
the interpretation of the pixel values can take several 
forms. Instead of hard-wiring one or two modes, the 
interpretation is variable on a per-pixel basis, allowing 
different windows to be displayed in different modes. In 
particular, the sixteen values specified by the four-bit 
interpretation mode or attribute index signals each se- 
lect one of sixteen attribute fields stored in interpreta- 
tion mode LUT 34. The per-pixel interpretation mode 
field can thus select one of sixteen ways of processing 
the RGB bits associated with each pixel in the planes of 
bitmap 32. 

Moreover, because cursor characteristics can also be 
encoded in these attributes, cursor activity and drawing 
activity do not affect each other, and thus the RGB 
image need not be corrupted by the cursor. 

In a preferred embodiment of the invention, there are 
eight pixel display modes, supporting a variety of false 
color v. real color, double buffering, and overlay com- 
binations. These combinations are illustrated in FIG. 5. 
Overlays are a separate image which is displayed "in 
front of 'or overlaying the normal image. When an 
overlay has a non-zero value, it forces the correspond- 
ing pixels to the overlay's color. When an overlay has a 
zero value, the underlying image is seen. Overlays are 
useful for annotating the underlying image. By main- 
taining such annotations on planes separate from the 
planes storing the normal image, the normal image is 
not corrupted, and the annotation can be edited, 
scrolled and otherwise processed independently. 

In a further preferred embodiment of the invention, 
each interpretation mode or attribute is specified by a 
seven bit field, as illustrated in FIG. 4. The seven bit 
field illustrated in FIG. 4 is stored in the bitmap 22 in 
the embodiment illustrated in FIG. 2, or in the interpre- 
tation mode table 34 in the embodiment illustrated in 
FIG. 3. The seven bits are used to specify a color 
lookup table origin, double buffer on/off selection, and 
plane multiplexing. The multiplexing values are used to 
combine and route data stored in the bitmap color mode 
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planes to addresses for the color lookup tables 36, 
which in a preferred embodiment are 2KX24 bits. 

Thus, the four-bit mode or attribute index values 
from bitmap 32 each select one of sixteen attributes, 
each of which in turn specifies the method by which 5 
bitmap planes or cursor color are assembled as a color 
LUT index for a given pixel. The attribute indexes are 
preferably updated whenever the cursor moves or the 
window configuration changes. 

The seven bit field illustrated in FIG. 4 includes three io 
LUT Bank bits, one Double Buffer Select bit, and three 
Pixel Mode or plane multiplexing selection bits. The 
three color bits that make up the LUT BANK provide 
the upper three color LUT index bits for pixel display. 
The Double Buffer Select bit selects which of two buff- 15 
ers is to be displayed for double-buffered windows. 

The three Pixel Mode or plane multiplexing selection 
bits specify eight ways of selecting and combining bit- 
map planes to produce a color LUT index. In a pre- 
ferred embodiment of the invention, those eight config- 20 
urations are defined as illustrated in FIG. 5. FIG. 5 
illustrates combinations of bits from 48 planes, num- 
bered zero through 47, in bitmap 32. The "Ov" and "0" 
bits are overlay bits, and the "C" bits are color bits. 

The eight configurations are eight-bit false color, 2 5 
eight-bit false color with four overlays, ten-bit false 
color with two overlays, twenty-four bit real color, 
twenty-three bit real color with one overlay, twenty- 
four bit real color, referred to as "four/four/four real 
color", mixed mode with four overlays, and constant j 
color. 

Software code utilized in conjunction with the dis- 
play modes according to the invention is set forth in 
Appendix 1, incorporated herein. 

In a preferred practice of the invention, a "fast clear" 35 
system is provided for rapidly clearing selected win- 
dows or an entire screen. This fast clear system can be 
implemented in either the "direct environment" of the 
embodiment illustrated in FIG. 2, or in the "indirect 
environment" of the embodiment illustrated in FIG. 3. ^ 

Thus, in a further preferred embodiment of the sys- 
tem illustrated in FIG. 3, supporting eight utility planes, 
each pixel can have these attribute bits stored in inter- 
pretation mode LUT 34: 

45 



50 



#bits 


Attribute 


3 


EITHER: Upper LUT bits or 




Cursor color 


1 


Cursor enable 


1 


Double Buffer select if 




fast clear disabled 


2 


Valid bits for each 




buffer for fast clear 




mode 


1 


Fast clear enable 



Z refers to Z-coordinate or depth information. 
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The "Double Buffer Select" bit selects which of two 
possible eight- to twentyfour-plane images is displayed 
on the screen. "Fast Clear Enable" and "Pixel Valid" 
attribute bits are provided in association with each 60 
pixel. In accordance with the invention, pixels with Fast 
Clear enabled can be bulk-reset to a background color 
by being marked as invalid. Drawing operations set the 
affected pixels as valid. The "Pixel Valid" bits are un- 
conditionally set and reset, but are ignored if "Fast 65 
Clear Enable"is off. 

Fast clear in the embodiment illustrated in FIG. 3 
requires two additional bits in the mode or attribute 



index Field stored in bitmap 32, and for each window 
class, an additional bit in the attribute or mode field 
stored in mode LUT 34. A "Valid Bit"for each pixel is 
required for each of the two buffers used when double 
buffering. Fast clear then makes use of the "Double 
Buffer Select" bit in the attribute field, and requires an 
additional "Fast Clear Enable" bit in the attribute field 
for each window class. 

When fast clear is used in the indirect environment, 
the "Fast Clear Enable" bit is set in the windows which 
are selected for fast clear treatment. Then the "Pixel 
Valid" bits are cleared using either a full screen clear 
operation or a window clear operation for the buffer 
which is selected by a respective "Valid Bit" for draw- 
ing. 

The "Buffer Select" bit shown in FIG. 4 is used by 
the video generating hardware to determine which 
buffer to display. This allows double buffering pixel by 
pixel, which is useful in double buffering individual 
windows. If "Fast Clear Enable" is "on" then the video 
generating hardware disregards the "Buffer Select" bit, 
and the determination of which buffer to display is 
made from a pre-programmed one bit register in plane- 
routing logic 35. For each buffer, the "Buffer Cleared" 
bit causes the video hardware to display preset values 
instead of the value in image memory. A Z compare 
mechanism, known in the art, is used to sample the 
"Fast Clear" bit and the appropriate "Buffer Cleared" 
bit to emulate reading a preprogrammed value from the 
Z buffer. 

When a window is operating in "Fast Clear" mode, 
all the "Fast Clear Enable" bits are set to "on" for this 
window, and "off for the rest of the screen. To swap 
buffers for this window, one register in the video sec- 
tion, or control logic 35, is reprogrammed. 

If two of the utility plane attribute bits for each pixel 
are allocated to represent "Pixel Valid" for each buffer, 
and the system substitutes a background color for the 
RGB value of every invalid pixel, then a window or 
sub-window can be implicitly cleared by clearing the 
"Pixel Valid" bits. In a preferred embodiment of the 
invention, drawing operations set this bit; Z-buffered 
drawing reads the bit to determine whether the Z value 
is valid, and then sets the bit. 

Because the "Pixel Valid" bits can be cleared quickly, 
the window is quickly cleared, because the display 
video will show the background color. Z-compares, 
known in the art, are forced to enable writing. 

Since the above-described mechanism can be gated 
by another "Fast Clear Enable" utility plane which has 
bits asserted only in the window of interest, a fast clear 
of all the valid bits, inside and outside the window, will 
have an effect only on the window pixels. A preferred 
embodiment of the invention executes fast clear of an 
entire plane utilizing VRAMs via a serial port. This 
eliminates the problem of serial write operations not 
being limitable to window boundaries. 

Thus, to clear a buffer, the appropriate "Buffer 
Cleared" bit is set for the entire screen. In accordance 
with the invention, the "Fast Clear Enable" bit is gated 
with the "Buffer Cleared" bit so that the "Buffer 
Cleared" bit only affects the desired window. More- 
over, any write operations to the buffer always turn the 
corresponding "Buffer Cleared" bit "off for each pixel 
that is written. 

In a system according to the invention, a buffer can 
be cleared much faster than with conventional systems 
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because the appropriate "Buffer Cleared" bit can be set 
for the entire screen without regard to the window 
boundaries. 

These "Pixel Valid" and "Fast Clear Enable" bits are, 
in a preferred embodiment of the invention, imple- 5 
mented with video RAMs (VRAMs), which can be 
gang-cleared, as known in the art, by writing to mem- 
ory through shift registers which form a part of the 
VRAMs. This permits swapping buffers and clearing 
the non-displayed buffer in a small fraction of a frame 10 
time. In a conventional system, assuming 12.5 nanosec- 
onds write time per pixel, clearing the entire screen 
would require 1280x1024X12.5 nanoseconds=0.98 
frame times (assuming 60 Hz refresh speed). The fast 
clear feature leaves about twice as much time available 15 
to writing the next image when executing real time 
(30Hz) animation. 

In summary, the fast clear feature of the invention 
utilizes the ability to set entire planes to fixed values 
very quickly to indicate state over a region that is stati- 20 
cally flagged. "Fast Clear Enable" flags the region, and 
"Buffer Cleared" bits indicate the state. "Fast Clear 
Enable" is preferably n bits wide, to define 2" display 



Appendix 1 



regions. 

A fast clear as described above does not invert the 
"Double-Buffering Select" bit, because that bit would 
have to be inverted only within the window of interest. 
Instead, in order to avoid double buffering pixels other 
than those in the window being cleared, the video hard- 
ware uses a "Mode Flop" bit as the "Double Buffer 
Select" for the selected window, detecting the selected 
window pixels by their "Fast Clear Enable" plane bits. 

It will thus be seen that the invention efficiently at- 
tains the objects set forth above. In particular, the in- 
vention provides an improved computer graphics dis- 
play controller system having a wide range of flexible 
display modes controllable by control information 
stored in association with each pixel. It will be under- 
stood that changes may be made in the above construc- 
tion and in the foregoing sequences of operation with- 
out departing from the scope of the invention. It is 
accordingly intended that all matter contained in the 
above description or shown in the accompanying draw- 
ings be interpreted as illustrative rather than in a limit- 
ing sense. 

atg_$ get_r gb .pas 



{ Subroutine ATG_$«ia^ .-a»- <X,1,SGB) 

* Return the 24 bit RGB value that would go to the D/A converters 

* for a given pixel coordinate. X and v are the coordinate of the 

* pixel. RGB is returned as 4 bytes. The first byte is not used. 

* The next 3 bytes are red, green, and blue in that order. 



* This subroutine takes into account the attribute bits, 

* the various pixel modes and the look up tables . 

) 

module atg_$get_rgb; 

define atg_$get_rgb; 

% include ' /olin_dsee/atg/atg2 . ins . pas ' ; 



and simulates 



attr: integer 16, • 

rlut, glut, blut: integer 16; 

class: wind_class_type; 

mode : integerl6 ; 

bank: integerl6; 

ov_mask : integerl6 ; 

pixel : ~atg_$ pixel_type ; 

status: status_$t; 

lut_adr: atg_$lut_adr_type; 

dac_val: atg_$argb_pixel_type; 



{attribute bits value at this pixel] 

{red, green, blue lut index values) 

{window class descriptor] 

{pixel mode with double buffer bit in LSB] 

{look up table bank mask] 

{overlay bits aligned at the lsb) 

{pointer to this pixel in bitmap] 

{error code] 

{composite LUT adr for watch LUT adr feature] 

{DAC data for watch DAC value feature] 



procedure atg_$get_rgb; 



label 

cursor, do_lut; 

* 

* Internal subroutine CHECK_OVERLAYS (N) 
* 

* Check for any overlay plane bits being turned on. N is the number of overlay 

* bits in OV_MASK. The highest priority overlay bit is in the lsb of OV_MASK. 

* Any unused high bits of OV_MASK should be set to zero. The value in OV_MASK 

* is trashed. 
* 

* If none of the overlay plane bits are found to be turned on (-1), then 

* CHECK_OVERLAYS just returns. Otherwise, RLUT, GLUT, and BLUT are set to the 

* appropriate values for the overlay plane found, and a jump is taken to 

* the label DO_LUT in the main subroutine. 



11 

} 

procedure check_overlays ( 
in n: integerl6); 
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[number of overlay planes] 



i: integerl6; 



{current overlay plane number) 



label 

f ound_overlay ; 



begin 

if ov_mask - then i . . J ia< . > 
for i :■ to n-1 do begin 

if (ov_mask Si) <> then 
goto found_pverlay; 

ovjnask :- rshft(ov_mask,l) ; 

end,- 
return ; 

f ound_overlay : 

rlut :- lshft( class. lut_bank S 7,4) 

rlut :- rlut ! i; 

glut :- rlut; 

blut :- rlut; 

goto do_lut; 

end; 



[all overlay bits orf ?) 

[once for each overlay plane] 

[this overlay plane bit is turned on ?) 

[we found an ON overlay plane bit] 

[shift next overlay plane bit into position) 

[back and check this new overlay plane bit) 

[did find any overlay bits on] 

[found highest priority overlay bit that was on] 
. 128; [block number based on lut bank number) 
[merge in offset within overlay block) 
[copy lut index to other colors) 

[lut indicies completely set, do look up] 



********************************************************************************* 



* Body of main routine. 

] 

begin 

pixel :- addr(bitmap[y,x] ) ; {make pointer to this pixel) 

attr :- pixel". attr; {get attribute index) 

class :- wind_class{attr] ; {get the window class in use for this pixel) 

mode :» lshft( class. pix_mode & 15,1) ! ( class . dbl_buf & 1); {mode with dbl buf bit) 



[ 



case mode of 

Mode 0, buffer 1. 
8 bit pseudo color. 



{8 pixel modes, each with buffer select option) 






begin 




rlut :- pixel". blul; 




glut := rlut; 




blut :- rlut; 


[ 

* 


end; 


Mode , buffer 2 . 


* 

) 

1 


8 bit pseudo color 


: begin 




rlut :•» pixel". grnl; 




glut :« rlut; 




blut :« rlut; 




end; 



{all lut indices to same value (false color)) 



[all lut indices to same value (false color)) 



Mode 1 , buffer 1 . 

8 bit pseudo color with double buffered 4 bit overlay planes. 



] 

2 : begin 

ov_mask :» rshft(pixel~.grnl,4) ; 

check_overlays ( 4 ) ; 



[get 4 overlay planes) 
[check overlay planes) 



rlut 
glut 
blut 
end; 



- pixel . blul; 

- rlut; 

- rlut; 



C ' __ 

* Mode 1 , buffer 2 . 

* 8 bit pseudo color with double buffered 4 bit overlay planes. 
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} 

3 : begin 

ovjnask :« pixel". grnl & 15; {get 4 overlay planes} 
check_overlays (4); {check overlay planes} 



rlut 
glut 
blut 
end; 



- pixel .grnl; 
= rlut; 
= rlut; 



* Mode 2, buffer 1. 

* 8 bit pseudo color with 16 bit overlays . 
} 

4 : begin 

ovjnask := lshft( pixel". grnl, 8) {assemble overlay bits} 
! pixel". redl; 

check_overlays (16); [check 16 overlay planes} 

rlut := pixel". blul; 

glut := rlut; 

blut :-= rlut; 

end; 
[ 

* Mode 2, buffer 2. 

* 8 bit pseudo color with 16 bit overlays . 
] 

5 : begin 

ovjnask :- lshft(pixel~.grn2,8) [assemble overlay bits} 

! pixel" . red2 ; 
check_overlays (16); [check 16 overlay planes} 

.blu2; 



rlut 


:» pixel 


glut 


:= rlut; 


blut 


:= rlut; 


end; 





* Mode 3, buffer 1. 

* 10 bit pseudo color with 2 overlay plane. 
} 

6 : begin 

ovjnask : — rshft( pixel". blul, 4) S3; 
check_overlays ( 2 ) ; 

rlut :« (rshft(class.lut_bank,8) S 16#400) {top bit comes from lut bank field} 
! (lshft(pixel~.blul,2) S 16#0300) {next two bits of lut bank} 
! pixel". grnl; {lut index within bank} 

glut := rlut; 
blut := rlut; 

goto do_lut; {LUT indicies all set} 

end; 

{ 

* Mode 3, buffer 2. 

* 10 bit pseudo color with 2 overlay plane. 

} 

7 : begin 

ovjnask := pixel". blul a 3; 

check_overlays ( 2 ) ; "•t a * r 

rlut i- (rshft(class.lut_bank,8) & 16#400) {top bit comes from lut bank field} 
! (lshft( pixel". blul, 6) & 1610300) [next two bits of lut bank} 
! pixel". redl; {lut index within bank} 

glut := rlut; 

blut :- rlut; 

goto do_lut; {LUT indicies all set} 

end; 
{ 

* Mode 4, buffer 1. 

* 24 bit real color. 
} 

8 : begin 



rlut 
glut 
blut 
end; 



= pixel .redl; 
= pixel". grnl; 
= pixel" . blul ; 



15 
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Mode 4, buffer 2. 
24 bit real color. 



t 



begin 
rlut 
glut 
blut 
end; 



pixel" . red2 
pixel". grn2 
pixel" . blu2 



* Mode 5, buffer 1. 

* 23 bit real color with 1 overlay plane. 
} 

10 : begin 

ovjnask :- pixel". blul & 1; 
check_overlays (1); 



rlut 
glut 
blut 
end; 



pixel . redl ; 
pixel". grnl; 
pixel". blul & 8 #37 6; 



[mask off low bit of blue] 



C 



« Mode 5, buffer 2 

* 23 bit real color with 1 overlay plane. 

} 

11: begin 

ov_mask :- pixel". blu2 & 1; 

check_overlays ( 1 ) ; 





rlut 


:- 


pixel" 


red2 ; 






glut 


:- 


pixel" 


grn2 ; 






blut 


:- 


pixel" 


blu2 i 


1 8#376; 


[ 

* 


end; 










Mode 


5, buffer 1. 




* 
1 


12 


bit real < 


:olor . 




J 

12: begin 










rlut 


:- 


(pixel 


" . redl 


S 16#0FO) ! 




glut 


:- 


(pixel 


" . grnl 


& 16#OF0) ! 




blut 


':- 


(pixel". blul 


v. .-X61IOF&t 1 


r 


end; 








<*• \k>£o?G) 



[mask off low bit of blue) 



« Mode 6, buffer 2. 

* 12 bit real color. 

} 

13: begin 

rlut :- (lshft( pixel". redl, 4) 
( lshf t ( pixel" . grnl , 4 ) 
(lshft( pixel". blul, 4) 



glut 
blut 
end; 



(rshft( pixel". redl, 4) s 16#0F); 
(rshft(pixel~.grnl,4) S 16#0F); 

(rshft( pixel". blul, 4) jp-x«iroF > ) ; 



16#0F0) ! (pixel". redl S 16#0F) 
16#0F0) ! (pixel". grnl S 16#0F) 
16#0F0) ! (pixel". blul 6 16#0F) 



[ 



* Mode 7, buffer 1. 

* 12 bit real color with 12 bits of overlay 
) 

14 : begin 

ov_mask := (rshft( pixel". blul, 4) & 16 # OOF) 
! (pixel". grnl & 16#0F0) 
! ( lshf t( pixel". redl, 4) & 16#0F00); 
check_overlays ( 12 ) ; 

rlut :- ( lshf t( pixel". redl, 4) & 16#0F0) 
(lshft(pixel~.grnl,4) S 16#0F0) 
( lshf t( pixel". blul, 4) S 16#0F0) 



glut 
blut 
end; 



(pixel". redl s 16#0F) 
(pixel". grnl fi 16#0F) 
(pixel". blul & 16#0F) 



[ 



) 



Mode 7, buffer 2. 

12 bit real color with 12 bits of overlay. 



15: begin 

ovjnask := (rshft(pixel~.blu2,4) & 16#00F) 
! (pixel". grn2 s, 16#0F0) 
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! (Ishft(pixel~.red2,4) & 16#0F00); 
check_overlays ( 12 ) ; 

rlut := (lshft(pixel~.red2,4) S 16#0F0) ! (pixel". red2 & 16#0F); 
glut := (lshft(pixel".grn2,4) & 16#0F0) ! (pixel". grn2 & 16#0F) ; 
blut := (lshft(pixel~.blu2,4) & 16#0F0) ! (pixel". blu2 & 16#0F) ; 
end; 



* Mode 8, buffer 1. 

* 8 bit double buffered pseudo color with 8 bit single buffered overlay. 
} 

16: begin 

ovjoask := pixel". grnl; 
check_pverlays ( 8 ) ; 
rlut :- pixel". blul, • 

rlut; 

rlut; 



glut 
blut 
end; 



t 



Mode 8, buffer 2. 

8 bit double buffered pseudo color with 8 bit single buffered overlay. 



} 

17 : begin 

ov_mask :«• pixel". grnl; 
check_overlays ( 8 ) ; 
rlut :- pixel". redl; _ 
rlut; 
rlut; 



glut 
blut 
end; 



C 



Mode 9. 

Cursor color. The high 8 bits of the LUT index come from the 
CURSOR ORIGIN register, and the low 3 bits come from the LUT BANK 
field in the window class descriptor. 



18 : goto cursor ; 






19: 








cursor : 


begin 






rlut 


: - ( cursor 


_origin 


fi 16#07F8) 


glut 


:- rlut; 






blut 


:= rlut; 






goto 


do_lut ; 






end; 









( class . lut_bank & 7 ) ; 



otherwise 

status. all :■> atg_$unimp_pix_mode; 

atg_$error (status, ' Uniplemented pixel display mode.'); 

return ; 



{unrecognized pixel mode, complain about it] 



{done with all the pixel modes} 



end; 

{ 

*********************************************************************************** 

* 

* The low 8 bits of RLUT, GLUT, and BLUT have been set. Add on the bank select 

* bits and index into the look up tables to find the real color. 



bank 
rlut 
glut 
blut 



lshft( class. lut_bank & 7,8); {position 3 bit lut bank field} 



= (rlut & 255) 
= (glut & 255) 
= (blut S 255) 



bank 
bank 
bank 



{merge bank onto indicies} 



RLUT, GLUT, and BLUT are the final look up table index values. Now use them 
into the LUT to get the real color. 



} 
do_lut : 

if lut_adr_proc <> nil then begin 

lut_adr . unused : = ; 

lut_adr.bank :=■= rshft(rlut, 8) ; 

lut adr.red := rlut s 255; 



{jump here from cursor colors} 

{somebody wants to watch all LUT addresses ?} 

{clear unused bits} 

[grab bank field from red LUT address] 

{offset into bank for each color} 



lut_adr . grn 
lut_adr . blu 
lut_adr_proc 
end; 

rgb. alpha 

rgb . red : ■ 

rgb . grn : ■ 

rgb. blu :■■ 

if dac_val_proo 
dac val . all : 
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■ glut & 255; 
' blut & 255; 
(x,y,lut_adr) ; 
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- 255; 

ord(red_lut[rlut] ) ,- 
ord(grn_lut [glut] ) ; 
ord(blu_lut [blut] ) ; 

<> nil then begin 
0; 



dao_val.red :« rgb. red; 

dac_val.grn :- *gb. j^- ^ 'd r ^J, 
dac_val.blu :« rgb. blu; ^ 
dac_val_proc~ (x,y,dac_val) ; 
end; 
end; 



[tell user of this LUT address] 

{set alpha value to max opaque] 
[index into LUTs to find real color] 



[somebody wants to watch all DAC color values ?) 
{init all bits to zero] 
{fill in 24 bit DAC color) 



{tell user of this DAC value] 



It is also to be understood that the following claims 
are intended to cover all the generic and specific fea- 
tures of the invention as described herein, and all state- 
ments of the scope of the invention which, as a matter of 
language, might be said to fall therebetween. 

Having described the invention, what is claimed as 
new and secured by letters patent is: 

1. In a system for controlling a computer graphics 
display, wherein said system stores and processes digital 
pixel values corresponding to respective display pixels, 
said system including a color component lookup table 
element having an array of memory locations for stor- 
ing digital color component values, the color compo- 
nent lookup table element being addressable by selected 
multiple-bit digital index values, the improvement com- 
prising 

storage means for storing first control values in asso- 
ciation with each digital pixel value, • 

display mode lookup table means, including an array 
of memory locations, the display mode lookup 
table being addressable by said first control values, 
for generating second control values correspond- 
ing to respective pixels, and 

control means, in communication with said display 
mode lookup table means and said storage means, 
for generating the multiple-bit digital index values 
in response to a combination of said second control 
values and said digital pixel values. 

2. In a system according to claim 1, the further im- 
provement wherein said control means includes means, 
responsive to said second control values, for writing 
said pixel values into said color component lookup table 
element. 

3. In a system according to claim 1, the further im- 
provement wherein said control means includes means, 
responsive to said second control values, for addressing 
the color component lookup table element with selected 
multiple-bit digital index values, wherein selected bits of 
said multiple-bit digital index values include said pixel 
values. 

4. In a system according to claim 1, the further im- 
provement 

wherein said storage means includes a plurality of 
memory locations organized into plural memory 
planes associated with given display areas, and 

wherein said control means includes means, respon- 
sive to said second control values, for designating a 
set of memory planes associated with each of said 
given display areas, and for selecting relative prior- 
ity of said memory planes associated with a given 
display area. 
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5. In a system according to claim 1, the further im- 
provement wherein said pixel values are represented by 
multiple bit data words, bit positions in said data words 
corresponding to selected pixel characteristics, and 
wherein said control means includes means, responsive 
to said second control values, for selecting pixel charac- 
teristics corresponding to bit positions in said data 
words. 

6. In a system according to claim 1, the further im- 
provement comprising 

memory means, including first and second memory 
buffers, for storing digital pixel values in said first 
and second memory buffers, and 

wherein said control means includes display control 
means for controlling the display in response to 
values stored in a selected one of said first and 
second memory buffers, said display control means 
includes buffer selecting means for selecting, in 
response to said second control values, one of said 
first and second memory buffers. 

7. In a system according to claim 1, the further im- 
provement wherein said storage means includes means 
for storing an override control value representative of 
an override color, and wherein said control means in- 
cludes means, responsive to said override value, for 
generating an override color output. 

8. In a system according to claim 1, the further im- 
provement wherein said system provides plural display 
windows, wherein said storage means includes means 
for storing a validity indicator associated with a given 
window, and wherein said control means includes 
means, responsive to said validity indicator, for substi- 
tuting pixel values representative of a predetermined 
state for pixel values associated with pixels correspond- 
ing to said window. 

9. In a system according to claim 1, the further im- 
provement wherein said storage means contains means 
for storing, in association with a given pixel, a third 
control value, said third control value designating, as 
time variant, other values stored with said given pixel, 
and wherein said control means includes means, respon- 
sive to said second control values, for varying said other 
values stored with said given pixel. 

10. In a system according to claim 1, the further im- 
provement 

wherein said storage means includes means for stor- 
ing display area control values, said display area 
control values designating selected display areas 
for predetermined drawing processing, and 

wherein said control means includes means, respon- 
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sive to said display area control values and said 
second control values, for masking off selected 
pixel values. 

11. In a system according to claim 1, the further im- 
provement 

wherein said storage means includes means for stor- 
ing arithmetic process control values indicative of 
selected arithmetic operations to be executed on 
pixel values corresponding to selected display ar- 
eas, and 

wherein said control means includes means, respon- 
sive to said arithmetic process control values and 
said second control values, for enabling execution 
of said selected arithmetic operations on said pixel 
values corresponding to said selected display areas. 



10 



15 



12. In a system according to claim 4, the further im- 
provement wherein 

said memory planes include a set of overlay memory 
planes, said overlay memory planes being arithmet- 
ically combinable in accordance with selected 
overlay plane encodings, 

said storage means includes means for storing overlay 
control values indicative of selected overlay plane 
encodings, and 

said control means includes means, responsive to said 
overlay control values and said second control 
values, for arithmetically combining selected ones 
of said overlay memory planes. 
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